So I was able to get some testing in today and the following are my findings.

Most of the functionality appeared to work as intended. Can't be sure I tested everything, but I did try to test the things you mentioned at least. The core stuff appeared to work, and as a result I'll mostly be talking about fringe cases.

1. As you expected !sayspectator did not function.
2. When spectating in CSR mode, I found I had suffered from collision with other non-spectator players. Intended?
3. Whilst vehicles successfully regenerate armour/shields to prevent death in CSR mode, Phalanx/Deployable Field Turrets did not, meaning they could be destroyed normally.
4. Whilst dying in a Phalanx/Deployable Field Turret in CSR mode you successfully were resurrected, in this case next to the now dead turret but requiring a /gmtoggle to become visible to other players again. The same can not be said for other vehicles whereby your death (say by falling into lava or the ol' /suicide locked you into "purgatory" unable to do anything and forcing a closure of the game.
5. Use of /gmtoggle, on or off, in most vehicles appeared to leave the 3rd person view limited to the view range of solider rather than the intended range of the vehicle (this was inconsistent),
6. Enabling /spectator on during CSR mode whilst inside an implant terminal or vehicle immediately crashed the game for the player doing so, and on a couple of occasions nearby players too. Doing this I managed to get one character stuck displaying spectator:NAME, I also did it to a second character but them somehow cleared it? It persisted through death, and relog otherwise.
7. There was some inconsistency with the ability to make use of certs/vehicles when toggling between CSR mode. I found whilst it displayed all certs as available on the character pane, I could only make use of certs the character had otherwise. Similarly one could not acquire armour or vehicles from terminals if they didn't already have the certification outside of CSR mode. This also extended to being unable to re-enter a vehicle that you exited after using /gmtoggle on whilst inside, though this would remedy after toggling the mode back off.
8. Somewhat related to the above, I found placing Combat Engineering entities to be broken. Attempting to place any would result in no resources being expended, a single boomer being placed, and you not receiving a trigger. Further attempts to place would be met with a message stating "you are busy" prevent placing more until you toggled CSR mode.
9. Last one is a bit more fun; MAXes have unlimited capacitor in CSR mode, allowing VS MAXes to fly to the moon. TR MAXes however get stuck in their overdrive mode with no ability to exit it due to this.

That's it for now, I'm sure Deth will find something I did not.

2. When you say "suffered from collision" do you mean you took damage? I attempted to disengage all of that. You still physically exist in the world on your own client but you should not cause or be inflicted by damage. I did not go through the standard spectator activation packets because I intended for CSR spectator to still be able to interact with terminals and such. There's a longer story about this but it's not very important right now. Should I just stick to normal spectator behavior?
3. Noted and will be fixed.
4. When you normally die in a vehicle, it kicks you out of the seat and conceals the corpse. I have to remember to undo that.
5. Weird. I'll research it a bit more.
6. I think I know why and can fix it easily.
7. Weird. I'll research it a bit more. (blatant copy paste)
8. Weird. I'll research it a bit more. (blatant copy paste) (blatant copy paste)
   Wait, wait, I can explain the lack of Boomer Trigger at least. The trigger is only awarded to the player who will be the owner and deployables placed by CSR's do not gain the CSR as an owner. The trigger does not spawn. Also, the server needs to reset the deploy animation but it does not thinks anyone one performed it.
9. Block the TR Max from using its special ability or reset the capacitor (and the capacitor ability) only after the capacitor has hit zero. Got it.

Sorry I should have clarified further from "suffered from collision", and it appears in my haste to get that typed up I also missed out "when spectating as CSR".

There was no damage but I found myself bumping into, being displaced by, and being unable to pass through other characters who were not spectating.

So yeah was bumping into others characters as a spectator in CSR mode.

Fixes have been applied, as per comment above:

2. CSR Spectator now utilizes standard spectator behavior mode benefits. That should remove most player collisions and even out door interactions. This does mean that they are now incapable of interacting with entities in the same ways that a normal spectator is. CSR commands will be expanded in the future to restore some functionality I wished they retain.
3. Mountables in general should now regenerate health and shields where applicable. The main issue was tying into the most obtuse of the upstream packets - the one where there is only KeepAliveMessage to know that the client is still connected.
4. CSR player should be visible when ejected from a mounted vehicle upon rare vehicle destruction. In fact ...
5. Activation of gmtoggle and spectator after that both kick the CSR player out of whatever he is mounted in at the moment. This should maintain the correct camera. Deactivation of gmtoggle also ejects the player from mounts.
6. See below
7. Corrected for certifications and probably for vehicle access. A CSR player will properly have access to all certifications, both in viewing their character stats and when using terminals and vehicle mounts and equipment. All other limitations for vehicle mounts should apply, sadly, so exo-suit requirements still restrict.
8. Deployable animation reset allows the CSR player to place multiple deployables with the same construction tool (ACE or FDU). The FDU has an unavoidable delay in anticipation of an animation that will never play but should still return control to the user shortly. Constructing a Boomer now properly creates a trigger, placing it in a hover right about the Boomer.
9. MAX capacitor now wraps around, draining when in use but becomingn 100% when zero'd. When the capacitor hits zero, TR MAX's turn off their special ability explicitly as it lacks a proper interupt keypress condition; but, all other MAX's should have their special abilities remain unlimited and persist between value changes.

In addition, I reversed my position of Handled and Unhandled returns from GeneralLogic: handleUseItem specific methods. I should have just created a flag to interrupt zoning cancel messages from the start.

In addition again, purchase timers for the CSR player should have less of a chance of interfering with purchases.

Chat is still busted and I have no prospects of fixing it right now. I'm working on tests for (6) just to make certain I am aware of conditions where this issue may arise.

Apparently, "the conditions where this issue may arise" are every time. I did what for it that I could.

The changes appear to have fixed the problems related to death in vehicles/mounts, but I found some other oddities;

1. Vehicles do appear to survive lava now with a CSR occupant but sometimes they will suddenly die. Best I can ascertain it appears to happen on game window loss/regain of focus?

2. CE stuff is still a little weird...

• Attempting to mount a field turret placed by a CSR will be met with a "busy" message. Curiously this appears to be due to the turret, not the player.
• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot
• Mines placed by a CSR either go off immediately (if you happen to be standing on/near them when placed), otherwise they never go off unless jammered
• Warning for ACE deployables are not show (e.g. too close message) they just fail silently. Does appear to work for FDU deployables though
• CE appears to be entirely ownerless and it doesn't get recorded against the limits of the placing avatar... which is I think is the point but thought I'd share nonetheless
• ACEs and FDUs are not consumed upon use whilst in CSR mode
• Technically from before these latest changes but somehow I managed to do this whilst in CSR mode: However been unable to replicate this one

3. I think with this version the strafing bug can be reliably triggered? Tangential, yes, but I found that using /gmtoggle when in a moving vehicle would reliably cause me to be strafing to the right after being ejected from the vehicle. Amusingly using /spectator in the same way (as a CSR) would regularly cause me to be stuck strafing to the left. I also found it sometimes happening whilst using auto-run and then using /gmtoggle. Inconsistently toggling back whichever mode was toggled would fix it, toggling another mode (e.g. spectator whilst CSR and vice versa) was more consistent in fixing. Best I can tell it appears to have something to do with being in a state of motion when your avatar is relocated? Can get footage if desired.

1. Best I can ascertain it appears to happen on game window loss/regain of focus?

Yeah, I can't do anything if it's that. Modern computer telephony and Internet architecture is no match for ancient packet deviltry.

• Attempting to mount a field turret placed by a CSR will be met with a "busy" message. Curiously this appears to be due to the turret, not the player.

You technically can't mount the turret because it is NEUTRAL and you are still whatever faction you belonged to at the start. That's why the empire insignia on the base is replaced with a white square.

• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot

They cause you no damage or they cause no other target any damage? If they do shoot at you, it might be a problem anyway.

• Mines placed by a CSR either go off immediately (if you happen to be standing on/near them when placed), otherwise they never go off unless jammered

Once again, the mine is NEUTRAL and you belong to a faction, and that's why they go off instantly. In fact, this moment of detection upon placement is the only time where the mine will detonate on its own initiate and not because a player or vehicle dared to move and exist too close. "Move" is the operative words in that condition. Otherwise, your CSR-privileged player does not interact with the zone like that. I'll check about any other player being a target of it's effect.

• Warning for ACE deployables are not show (e.g. too close message) they just fail silently. Does appear to work for FDU deployables though

I did hide a lot of messages in CSR mode, though I don't know what happened to this one.

• CE appears to be entirely ownerless and it doesn't get recorded against the limits of the placing avatar... which is I think is the point but thought I'd share nonetheless

Intended. In fact, because it is ownerless, it originally only had a default three minute decay. I had to intentionally tell it that it has a twenty minute delay.

• ACEs and FDUs are not consumed upon use whilst in CSR mode

Intentional and not a big deal. Being able to place deployables as a CSR is all about setup, not combat.

• Technically from before these latest changes but somehow I managed to do this whilst in CSR mode:

Totally keeping this bug, whatevere it is

3. I think with this version the strafing bug can be reliably triggered? Tangential, yes, but I found that ...

No, I noticed this too. Since the unstoppable side-strafe bug is an old client issue, solving the actual problem is beyond us. It did give me an idea about how we might finagle use from it with PlayerStateShiftMessage but I don't know if my idea would work yet.

4. CSRs are visible to other players after dying in a vehicle, but not to themselves:

10. Something small: Is this progressive XP something that should happen between all the revivals?

11. If you toggle GM powers on and then DC/crash and relog, you will have the merits on your arm still without any of the powers. If you then toggle GM mode on and off, you will continue having them on your arm, even though they should normally disappear when toggling off.

12. I was doing a test in lava, blowing up a CSR Fury with a BFR. The vehicle blew up and the CSR died and got DCed. I relogged, toggled GM on, got a new Fury and moved to the same spot, this time outside of the lava. DCed just from being shot at:

A few relogs later I couldn't enter my previously owned Fury and all my ammo was down to 1 for each weapon. Toggling GM on gave me my inventory items/ammo back, but still couldn't enter these vehicles because I was missing the certs for them now? Probably related to issue 7.

• Spitfires (and variants) placed by a CSR cannot cause harm (outside of detonating on death), but they do shoot

They cause you no damage or they cause no other target any damage? If they do shoot at you, it might be a problem anyway.

The spit tracks but doesn't fire unless fired upon first. It doesn't do damage to character avatars, nor vehicles whilst they are occupied. It does however damage empty vehicles?

Also something I found here; knives don't deal damage in CSR mode.

The knifing issue was actually a range issue that has probably persisted in the server for a while. The difference between normal stabbing distance and testable stabbing distance was some one-hundreth of a meter against, and this did not affect the katanas because the katana's test against one extra meter. It's still possible to make knife stabs connect with the target within the correct distance but it's hard to do when standing still, probably easier to do when constantly moving towards the target since that causes temporary overlap. In any case, the solution was an additional meter on the testable stabbing distance by increasing projectile lifespan.

I discovered that the spitfire refactor had a few issues and corrected them. For starters, rather than isolating a target when no existing target can be found, it would incorrectly return no projectile information and that short-circuits the whole process. Secondly, because it looked for having no target to cause damage rather than a confirmed target to cause damage, it only caused damage against a target the first hit and no time after that.

Changes to how player characters interact with the blockmap has resulted in CSR's not being interactive with environmental fields anymore. These changes have also allowed other entities that probe the blockmap to never encounter these "uneffected targets" while they are now allowed to remain as blockmap entities.

Killing a CSR player should no longer result in experience gain and suppress some other messages, in the logs especially. Also, the player should remain visible, hopefully.

Incidentally, as a CSR, if you drive a vehicle into lava, you will more easily see an understated feature of how lava damage was coded and the amount of damage a target receives is related to the depth of the target. Health is restored to the vehicle near instantly; but, the amount of health stripped off the vehicle in one go is easily visible in the brief moment of red status; and, the deeper the vehicle is driven, the larger that momentary red status. Driving around the crater allows the user to watch the health of the vehicle seasaw with depth. It's even possible to do this with an ATV without destroying the ATV.

By the way, I was unable to confirm an unfocused game window causing a build-up in damage as was suggested. I only had one instance of two ticks of damage before the CSR auto-heal kicked in. Personally, I find it strange that it happened at all.

By the way, I was unable to confirm an unfocused game window causing a build-up in damage as was suggested. I only had one instance of two ticks of damage before the CSR auto-heal kicked in. Personally, I find it strange that it happened at all.

Hmmm, it appeared to coincide with that when it happened for me. But it is true I couldn't get it to replicate consistently either. Chalk it down to "because PlanetSide" I guess? Whatever the cause, I did describe it as a fringe case so I doubt it'll go on to cause problems.

I corrected the issues in #1245 here in CSR because I wanted to correct the issue but then realized that I changed a part of the code critical for the bug fix in this PR.

Router and router pad SEP works.

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory:

Toggling GM while being dead can lead things like being stuck on the map screen if you attempt to use /zone. GMtoggle should probably be disabled whilst dead?

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory

That's normal spectator mode, correct? not csr spectator?

Zoning in spectator mode doesn't work properly. You end up in some inbetween state with broken weapons and inventory

That's normal spectator mode, correct? not csr spectator?

Just tested this myself and it appears to be during just normal spectator.

Yep normal spectator mode.

To add, this spectator zoning issue existed already. Tested on local (up-to-date minus this PR). The spectator that just zoned is visible to others, but frozen in place.

You don't want to shoot them!

This was amusing 😄 Do these deaths actually count against the gm?
https://github.com/user-attachments/assets/d109ad16-7cba-4464-b6d5-bd3f85c69355

My comment about spectators in only still partially true. They no longer become visible to others upon zoning (thus can't be shot at), but the avatar/inventory issue is still there. Should have fully tested here too...

For the record, attempting to zone as a spectator deactivates spectator mode and returns the player to their sanctuary.
A player should not be able to activate csr or spectator while dead.

As Fate said, attempting to /zone while a spectator did send me to sanc.
& while dead, attempting to /gmtoggle or /spectator gave the 'you do not have permission...' message.

A field turret constructed by a CSR-level player is now completely neutral. Although it's mounted weapon can not be seen or interacted with, that's merely a limitation of the client. The default field turret weapon is just a transparent parent object from which the faction others are instanced. It should function without crashing even if the user were capable of mounting the turret seat. When a deployable is constructed by a CSR-level player, the GUID of the resultant deployable is printed in event chat.

Included also is a new custom bang command called setempire which allows the CSR-level player to change the faction affiliation of a game object. Usage is !setempire <guid> [faction]. Entities must be represented by their current GUID. A faction must be represented by its two letter code and NEUTRAL is not allowed; if not listed, the player's current faction is selected. Entities behave differently based on how to most appropriately reflect a changed faction affiliation, e.g., field turrets (like above) deconstruct the old one and completely fabricate a new turret, facilities flip faction affiliation like being captured, facility amenities behave as if they were hacked, etc.. Certain entities such as players and Boomers do not change faction affiliation for obvious limitations.

As a combination of these features: !setempire on a field turret will construct a turret with a mounted weapon appropriate to the faction in question.

CSR field turret and setempire both seemed fine from the little bit I did with them. Is there a way to get a guid without using /destroy? For an equipment terminal, that seemed to make the terminal not work for the empire I set it to with the setempire command, but leaving and reentering the zone allowed that character to use the terminal as if it were hacked. Not sure if destroy did something to the terminal or it is just something with the setempire command.

/destroy is a horrible command that actually affects the environment of your game client and the server does not get polled for its permission. Of course, any changes to it are undone by merely reloading the zone for the majority of cases; but, for the duration while in that zone. anything with a GUID can be "killed". The only benefit of the command was that it displayed the GUID of an element in the events chat and that lost developmental usefulness to us immediately after we determined how to process hit information from projectile damage.

At the moment, !setempire is only best utilized for manipulating deployables that a CSR-user places in the game environment. All deployable entities should have their GUID posted to your events chat. Even the field turret that gets remade by setempire announces its GUID.

To answer you question directly, no, I've found no other commands that have the same affect. I was working on a "nearest" bang command to reveal the GUID of some nearby entity but I lost my battle with useful parameterization. My ultimate goal for CSR players is to use specific direct hit weapons to reveal debugging information about game entities rather than cause damage. Knives, anniversary pistols, and the sniper equipment are probably the best outlet for this since they shoot straight and behave the same way regardless of who holds them.

/capturebase doesn't work using the character's location anymore, this makes capturing bases in caverns and towers harder or impossible.

Can't be helped if it's the caverns. Those places aren't expected to have all their working bits and bobs and may not even play nicely with well-established commands.

As for the overworld, a change I introduced for CSR's meant that they no longer were being recognized as players in an SOI and, by not being recognized as players in an SOI, a shortcut I was using to assess their current faciltities by curr was not longer working. I've gone back to doing the math to check if they're in the SOI and that should resolve the issue.

SOI capturebase works again.

I reproduced the BFR particle cannon disconnect yesterday:

My current theory is that the disconnect is caused by the first damage tick of the radiation field. Unfortunately I haven't been able to repeat it since. I'm also not sure if this can be reproduced on the main server or if it's something that only happens here.

if i recall there a a bug with the Radiator making ppl crash as well

If the NC Particle Cannon and the AT Radiator are both infrequent issues, then the commonality might be a flaw in the remote projectile system, or a flaw in the radiation field damage calculations, related though different as they are. I am not going to attempt to extend this PR's scope again. That will be a different fix.

Using gmtoggle repeatedly before entering/exiting vehicles can lead to a severe slowdown in actions and weird stuff happening. If you do it for long enough, characters trying to load the continent will crash too.

Spam G to enter a vehicle and the mounting will take place at a random time in the near future, even while driving another vehicle:

Preventing users from exiting vehicles with gmtoggle might fix a good part of this.